1. Technical Field
The present invention is generally directed to an improved data processing system and method. More specifically, the present invention is directed to a system and method for automatically hiding sensitive information that may be obtainable from a process table.
2. Description of Related Art
The process table is a table containing all of the information that must be saved when a processor switches from running one process to another in a multitasking computer system. The information in the process table allows the suspended process to be restarted at a later time as if it had never been stopped. Every process has an entry in the process table. These entries are known as control blocks and contain the process state, memory state and resource state for the corresponding process. The process state is the information needed so that the process can be loaded into memory and run, such as the program counter, the stack pointer, and the values of registers. The memory state is the details of the memory allocation, such as pointers to the various memory areas used by the program. The resource state is the information regarding the status of files being used by the process, such as a user ID file and a password file. Other parameters of the process may be stored in the process control block as necessary. An example of a process table is shown in FIG. 1.
In many operating systems, commands are provided for gaining access to the process table. For example, the “ps” command in the Linux, Unix and AIX operating systems allows information from the process table to be displayed for every process running on the computing system. In some situations, such commands may allow an unauthorized user to gain access to sensitive information that is stored in association with a process in the process table.
For example, when a user enters a command in a command line of the operating system, the command initiates a process which causes a process table entry to be created. This command may include sensitive information, such as a user identifier and password, credit card information, security key information, and the like. For example, the command “>dbaddcmd -a ADD -u genty -p user_pwd” adds a user whose user name is “genty” and whose password is “user_pwd” to an authorized user file in a local database.
As shown in FIG. 1, in response to this command being entered into the command line, a process is initiated and its corresponding process control block 110 is added to the process table 100. The process control block 110 includes the command 112 which designates the user name and password. Any user, even one that is not a root user may enter the “ps -ef” command and have the process table entry corresponding to process control block 110 displayed for their viewing. As a result, an unauthorized user that enters the “ps -ef” command may obtain access to this user name and password. This is a significant security problem.
There are basically two known solutions to this problem, neither of which provide an optimum solution. A first solution is to not allow a command line argument on a particular command. In this case, the user must execute the command and the command waits for standard input. The user then enters the input, which may be the sensitive information. Since the input is not a process, the input from the user is not recorded in the process control block for the command in the process table. An example of this solution is shown below:
>passwd genty
Changing passwords for “genty”:
“genty”'s Old password:
Thus, in the above example, the command that would be entered into the process table is “passwd genty” and the actual password that is entered by the user at the prompt “Old password:” would not be displayed in the process table. The drawback of this solution is that users want to put script wrappers that automate the process around the command. That is, in order to automate the changing of a plurality of user passwords, a script wrapper may be placed on the command “passwd”. However, in the above case where user input to a prompt is required, the script wrapper will not function appropriately. That is, the automation is negated by the need for user prompted input.
A second solution to the problem of sensitive information being accessible via the process table is to empty out the arguments of the command code that deals with sensitive information. For example, in the example command provided above, the sixth argument is associated with a password. Thus, the logic that handles the commands entered via the command line may receive the command, initiate a corresponding process and generate a corresponding process control block in the process table. Thereafter, the password may be copied to a variable and then the password argument may be set to null so that other processes cannot see it via the process table. The drawback of this solution is that there is a window of time between the creation of the process control block and the execution of the process that nulls the password argument. If an automated mechanism is used to continuously enter the “ps -ef” command, it is possible that the “ps -ef” may capture the process control block prior to the argument being nulled.
Thus, it would be beneficial to have an improved mechanism for securing sensitive information from being accessed via the process table. More specifically, it would be beneficial to have a system and method that maintains the security of sensitive information while permitting script wrappers to be used and eliminating windows of time when the sensitive information may be accessible via the process table.